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The  challenge  -1 


WE  START 
SHIPPING  IN 
TWO  WEEKS. 


THAT'S  NOT  ENOUGH 
TIKE  TO  FIX  THE 
KNOWN  BUGS. 


OR  PERHAPS  IT  CAN 
ONLY  BE  OPERATED 
BY  A  ROBOT  FROK  THE 
FUTURE  WHO  JACKS 
INTO  IT  AND  SENDS 
COKKANDS  IN  ZEROS 
AND  ONES. 


WHEN 
YOU  SAY 
"BUGS/' 
THAT'S 
SORT  OF 
A  GRAY 
AREA.  . 
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UK. .  .1 
DONT 
THINK 
IT  IS. 
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FOR  EXAKPLE,  A  USER 
KIGHT  NEED  SEVERAL 
STEPS  TO  DO  SOKE- 
THING  THAT  SHOULD 
ONLY  TAKE  ONE. 


THAT'S 
SORT  OF  A 
GRAY  AREA. 


Tradeoffs  and  their  dependencies  must  be  supported  by 
both  Agile  software  development  and  architecture  practices. 
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The  challenge  -2 

First,  more 

II 
IE 
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!  /I 

lore  capabilities 

■£■  j 


underestimated 
re-architecting  costs 

Then ,  more  infrastructure 


need  to  monitor 
to  gain  insight 
into  life-cycle 
efficiency 


First ,  more  infrastructure 


Brown,  N.,  Nord,  R.,  and  Ozkaya,  I.  “Enabling  Agility  Through  Architecture.” 
Crosstalk 23,  6  (Nov./Dec.  2010):  12-17. 
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Then ,  more  capabilities 


neglected  cost  of 
delay  to  market 
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Increased  visibility  into  delivery 


Focus  on  Priority 


Velocity 


12 

10 

8 

6 

4 

2 

0 


Focus  on  Cost 


Velocity 


fc  i  H  Bl . 

Use  metrics  to 
monitor  &  select 
development 
tasks 


Focus  on  Integrated  Value 


Velocity 
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Agenda 

Symptoms  of  failure 
Concepts  of  scale 
Root-cause  analysis 
Architectural  tactics  that  can  help 
Typical  problems  and  their  resolution 
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Symptoms  of  failure 


■  Teams  spend  almost  all  of  their  time  fixing  defects,  and 
new  capability  development  is  continuously  slipping. 

■  Integration  of  products  built  by  different  teams  reveals  that 
incompatibilities  cause  many  failure  conditions  and  lead  to 
significant  out-of-cycle  rework. 

■  Progress  toward  meeting  milestones  is  unsatisfactory 
because  unexpected  rework  causes  cost  overruns  and 
project  completion  delays. 
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Today’s  Challenge  Dealing  with  Large 
Organizational  Changes 


Yesterday’s  Agile: 

Teams  got  better  at  building 
software 

■  Velocity 

■  Reliability 

■  Code  quality 

■  Improvement 

■  Cohesion 


Today’s  Agile 

Moving  the  rest  of  the 
business 

■  Timelines  have  changed 

■  Collaboration  is  critical 

■  Priorities  are  larger  than  the 
development  team 

■  Value  needs  clearer  definition 


Grant,  T.  “Navigate  the  Future  of  Agile  and  Lean.”  Forrester,  January  10,  2012. 
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A  closer  look  at  scale:  Scope 


Is  the  project  in  a  new  domain  or 
technology? 


Does  the  project  have  new 
requirements  such  as  standards 
compliance,  system  testing,  and 
integration  lab  environments? 

Is  there  a  need  to  align  systems 
engineering  and  software 
development  activities? 
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A  closer  look  at  scale:  Team 


Are  there  multiple  teams  that 
need  to  interact,  both  internal 
and  external  to  the  organization? 

at  are  the  dependencies 
veen  the  work  products  of 
:em  and  software  engineers? 


is  the  end-to-end  delivery  of 
ures  require  resources  from 
tiple  teams? 
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A  closer  look  at  scale:  Time 


□  Does  the  work  require 
different  schedule 
constraints  for  releases? 

□  How  long  is  the  work 
product  expected  to  be  in 
service? 

□  How  important  are 
sustainability  and 
evolution? 
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Polling  question 


How  would  you  describe  your  development  context? 

1.  We  follow  one  Agile  methodology  as  closely  as  we  can 

2.  We  use  a  mix  of  Agile  methodologies 

3.  We  mix  Agile  and  non-Agile  techniques 

a.  Waterfall  and  agile  hybrid 

b.  Architecture  and  agile  principles 

4.  We  do  not  apply  any  Agile  method 
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Root-cause  analysis 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 

Understand  symptoms  by  investigating  Agile  software 
development  and  software  architecture  principles  and 
practices  in  the  context  of  the  product  and  the  project. 
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Root-cause  analysis 


Response  to  change 

•  Dynamic  environment  and  changing 
requirements 

•  Necessary  technology  and  processes 

•  Impact  of  uncertainty 

Culture 

•  Skills  and  knowledge  and  clear 
responsibilities. 

•  Clear  communication  among  teams 

•  High-level  management  support 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 
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Root-cause  analysis 


Quality  attributes 

•  Quality  attribute  requirements  tied  to 
business  goals 

•  Quality  attribute  analysis 

•  Measurement  environment 

Architecture 

•  Evidence  that  the  architecture  satisfies 
quality  attribute  requirements 

•  Architectural  issues  {e.g.,  technical  debt) 

•  Timeline  of  critical  decisions 


Business 

Response  to 
Change 

Culture 

Team  Support 

Quality 

Attributes 

Customer 

Collaboration 

Architecture 

Productivity 

Measures 
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Architectural  tactics  to  consider 


Align  feature  and  system  decomposition. 
Create  an  architectural  runway. 

Use  matrix  teams  and  architecture. 
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Support  for  Development  Teams  Over  Time 


Desired  state  that  enables  agile  teams  to  quickly  deliver 
releases  that  stakeholders  value. 

State  of 
agile  team 
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Align  feature  and  system  decomposition 


Tension  between  high-priority  features  (vertical  decomposition) 
versus  common  reusable  services  (horizontal  decomposition) 


Infrastructure-driven 

approach 


Applications 


Services 


Drivers 


Horizontal  decomposition 
(e.g.,  layers) 


Feature-driven 

approach 


Csl 

<D 

L- 

D 

ro 
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Vertical  decomposition 
(e.g.,  subsystems,  features) 


Hybrid  approach 


Services 


Drivers 
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Align  feature  and  system  decomposition 


Layered  architecture  with  frameworks 


Dependencies  between  stories  and 
architectural  elements 

enables  staged  implementation  of  infrastructure 
in  support  of  achieving  stakeholder  value. 

Dependencies  among  elements 

Low-dependency  architectures  are  a  critical 
enabler  for  scaling  up  Agile  development.1 

Dependencies  among  stories 

High-value  stories  may  require  implementation 
of  lower  value  stories  as  precursors.2 


Decouple  teams  and  architecture  to  ensure  parallel  o— -■ 

progress  as  the  number  of  teams  increases. 

1 .  Poppendieck,  M.,  and  Poppendieck,  T.  Leading  Lean  Software  Development.  Addison-Wesley  Professional,  2009. 

2.  Denne,  M.,  and  Cleland-Huang,  J.  Software  by  Numbers.  Prentice  Hall,  2003. 
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Create  an  architectural  runway 


The  architectural  runway  provides  the  degree  of 
architectural  stability  to  support  the  next  n  iterations  of 
development. 

In  a  Scrum  project  environment,  the  architectural  runway 
may  be  established  during  Sprint  0. 

Sprint  0  might  have  a  longer  duration  than  the  rest  of  the 
sprints. 


The  bigger  the  system,  the  longer  the  runway. 
Principles  of  Agile  Architecture1 


1 .  Leffingwell,  D.  Agile  Software  Requirements,  Addison-Wesley,  201 1 
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Use  matrix  teams  and  architecture 


In  its  simplest  instantiation,  a  Scrum  development 
environment  consists  of: 

•  a  single  co-located,  cross-functional  team 

•  with  skills,  authority,  and  knowledge  to  specify  requirements 

•  and  architect,  design,  code,  and  test  the  system. 

As  systems  grow  in  size  and  complexity,  the  single-team 
model  may  no  longer  meet  development  demands. 

Strategies  to  scale  up  the  overall  agile  development 
organization  include: 

•  replication  of  team  structure  and  responsibilities 

•  hybrids  of  vertical  and  horizontal  team  organization. 
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Use  matrix  teams  and  architecture 


Feature  development  in  parallel 


#  Team  member  with  feature  responsibility 
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Root-cause  analysis:  Typical  problem  1 


Symptom 

•  Scrum  teams  spend  almost  all  of  their  time  fixing  defects,  and 
new  feature  development  is  continuously  slipping. 

Root-cause 

Inability  to  manage  scope  and  time  at  scale 

•  Initial  focus  was  “general”  rather  than  “product  specific.” 

-Time  pressure  to  deliver  became  the  top  priority. 

-The  team  delivered  an  immature  product. 

-A  plethora  of  variation  parameters  interact  detrimentally. 

•  There  are  three  different  cycles: 

-  Customer  release  (annually,  many  variants) 

-  IV&V  Testing  (quarterly,  4  variants) 

-  Developmental  (monthly,  1  variant) 
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Solution 


Stabilize  the  architecture. 

•  Add  guidelines  over  time. 

•  Reduce  the  number  of 
“variant  parameterizations.” 

•  Make  everyone  play  from 
the  same  sheet  music. 

•  Postpone  adding  new 
features. 


Replan  the  release  cycles  and  time  boxes. 

Revisit  the  testing  strategy  and  team  assignments  against 
variants. 
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Root-cause  analysis:  Typical  problem  2 


Symptom 

•  Integration  of  products  built  by  different  Scrum  teams  reveals 
that  incompatibility  defects  cause  many  failure  conditions  and 
lead  to  significant  out-of-cycle  rework. 

Root-cause 

Inability  to  manage  teams  at  scale 

•  Cross-team  coordination  is  poor,  even  though  there  are  many 
coordination  points  and  much  time  spent. 

•  Different  teams  have  different  interpretations  of  interfaces. 

•  The  product  owner  on  each  team  does  not  see  the  big  picture. 

•  A  mismatch  exists  between  the  architecture  and  development. 
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Solution 


Scrum 
Team  A 


Stabilize  to  remove  failures. 

•  Postpone  adding  new  features. 
Identify  and  collapse  common 


Temporary 
sprint  tea 


1 


I  API  |  | 


Layer 


Scrum 
Team  B 


i, 


services  across  teams. 

Use  an  architectural  runway. 

•  infrastructure  allows  incorporation 
of  anticipated  requirements 
without  excessive  refactoring. 

•  as  important  as  requirements 
epics  that  drive  the  company’s 
vision  forward. 

Teams  are  assigned  to  different  features,  a  temporary® 
team  prepares  layers  and  frameworks  for  future  teams. 
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Final  thoughts 


No  one  tactic  alone  can  take  any  project  to  success. 

Systematic  root-cause  analysis  is  essential  for  understanding 
risks  arising  in  large-scale  software  development. 

There  are  different  aspects  of  scale  to  be  managed  with 
different  approaches,  such  as  scope,  team,  and  time. 

Embracing  the  principles  of  Agile  software  development  and 
software  architecture  provide  improved  visibility  of  project 
status  and  better  tactics  for  risk  management. 
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